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MF.THOD FQ P BF.SOURCF, CONTROL 
INCLUDING PF.SOIIRCE STEALING 

A portion of the disclosure of this patent document contains material which is subject 
5 to copyright protection. The copyright owner has no objection to the facsmnle 

reproduce by anyone of the patent document or patent disclosure as it appears m the 
Patent and Trademark Office patent file or records, but otherw 1S e reserves all 
copyright rights whatsoever. 

10 BACKGROUND INFORMATION 

Traditional multitasking operating systems (e.g., UNIX, Windows) have been 
.mplemented in computing environments to prov.de a way to allocate the resources of 
the computing environment (e.g., CPU, memory, Input/Output (I/O) devices) among 
15 various user applications that may be running simultaneously in the computmg 

environment. The operating system itself includes a number of functions (executable 
code) and data structures that may be used to unplement the resource allocation 
serves of the operating system. A program that performs actions may be referred to 
as a task (also known as a "thread"), and a collection of tasks may be referred to as a - 
20 "process". Upon loading and execution of the operating system into the computing 

environment, "system tasks" and "system processes" are created in order to support the 
resource allocation needs of the system. User applications likewise, upon execution, 
may cause the creation of tasks ("user tasks") and processes ("user processes") m order 
to perform the actions desired from the application. 

Systems may often include shared resources that when accessed by a first task, should 
not be subsequently accessed by a second task until the first task's use of the resource 
has been completed. Examples of such shared resources may include a tape, a table m 
a database, a critical region in memory, etc. Operating systems may include one or 
30 more mutual exclusion control mechanisms, e.g., disabling interrupts, preemptive 
locks, or mutual exclusion semaphores, that may be used to prevent a second task's 
access to such shared resources while the resources are in use by a first task. 

Operating systems also may include a priority control mechanism to control the 
35 execution of both system and user tasks. In a prionty control mechamsm, tasks may be 
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assigned a priority value, e.g., a number ranging from a lowest priority to a highest 
priority. When multiple tasks contend for resources, a higher priority task generally 
receives more resources from the system than a lower priority task. A system 
including a priority control mechanism generally will not force a higher priority task 
5 to wait for a lower priority task to complete, but instead, where possible, may preempt 
the lower priority task until the high priority task either terminates, has its priority 
lowered, or stops for some other reason. 

Some systems include so-called "absolute" priority control mechanisms. In an 
10 "absolute" priority control mechanism, lower priority tasks never preempt higher 

priority tasks. A higher priority task generally receives all available system resources 
until it completes, or until an even higher priority task interrupts the task. However, 
altering the control of a critical shared resource in the middle of the lower priority 
task's use of the resource may jeopardize the integrity of the resource. For example, 

15 if the lower priority task is currently writing to a table in a database, allowing another 
higher priority task to write while the lower priority task's write operation is in 
progress may damage the integrity or consistency of the table. Therefore, mutual 
exclusion control mechanisms may be configured to allow a lower priority task to 
maintain control of a critical shared resources even when the lower priority task is 

20 preempted by a higher priority task. 

Figure 1 illustrates a problem that may occur in a conventional system that includes a 
mutual exclusion control mechanism and a priority control mechanism. A lower 
priority task, task B, may be executing, as shown at point 102. At point 104, task B 
25 requests a resource currently held by another, higher priority task, task A. The 
resource is protected by a mutual exclusion control mechanism, i.e., the resource 
cannot normally be taken from a task that is using it, irrespective of the task's priority. 
(Note that, even in a system with an absolute priority control mechanism, task B might 
be executing while the higher priority task A waits, because task A is waiting for 
30 another, different resource.) Because the resource needed by task B is currently held 
by Task A, task B blocks, and waits for the resource. At some later time 106, the 
higher priority task A resumes executing. At time 108, task A finishes using the 
resource that was requested by task B. Task A releases the resource, and may give it 
to task B, depending on how resource control mechanisms are implemented in the 
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system. For example, if the resource was controlled by a mutual exclusion 
semaphore, task A might gl ve the semaphore to task B. Task B is denoted here with a 
circle rather than a rectangle to indicate that Task B does not actually execute at time 
108. Instead, the resource is simply assigned to Task B during Task A's execution. 
After giving the resource to task B, task A resumes executing until time 110. At 110, 
task A requests the resource. However, the resource is now held by task B, so task A 
blocks on the resource. Task B may begin executing, and continue executing until 

1 12. At 1 12, task B finishes with the resource and returns the resource to task A, 

allowing task A to unblock and continue execution. 

SUMMARY 

In accordance with an example embodiment of the present invention, a method may 
be provided that includes assigning a resource to a holding task, receiving a request by 
a higher priority task to take the resource, the higher priority task having higher 
priority than the holding task, determining whether the holding task has used the 
resource since the resource was assigned to the holding task, releasing the resource 
when the higher priority task requests to take the resource and the holding task has not 
used the resource since the resource was assigned to the holding task, and assigning 
the resource to the higher priority task. 

In accordance with an example embodiment of the present invention, a method may 
be provided that includes assigning a semaphore to a holding task, the semaphore 
being a mutual exclusion semaphore, receiving a request by a higher priority task to 
take the semaphore, the higher priority task having higher priority than the holding 
task, determining whether the holding task has executed since the semaphore was 
assigned to the holding task, releasing the semaphore held by the holding task when 
the higher priority task requests to take the semaphore and the holding task has not 
executed since the semaphore was assigned to the holding task; and assigning the 
semaphore to the higher priority task. 



30 



In accordance with an example embodiment of the present invention, an article of 
manufacture may be provided, the article of manufacture including a computer- 
35 readable medium having stored thereon instructions adapted to be executed by a 
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processor, the instructions which, when executed, define a series of steps to be used to 
control a method for resource control, the steps including assigning a resource to a 
holding task, receiving a request by a higher priority task to take the resource, the 
higher priority task having higher priority than the holding task, determining whether 
the holding task has used the resource since the resource was assigned to the holding 
task, releasing the resource when the higher priority task requests to take the resource 
and the holding task has not used the resource since the resource was assigned to the 
holding task, and assigning the resource to the higher priority task. 

In accordance with an example embodiment of the present invention, an article of 
manufacture may be provided, the article of manufacture including a computer- 
readable medium having stored thereon instructions adapted to be executed by a 
processor, the instructions which, when executed, define a series of steps to be used to 
control a method for resource control, the steps including assigning a semaphore to a 
holding task, the semaphore being a mutual exclusion semaphore, receiving a request 
by a higher priority task to take the semaphore, the higher priority task having higher 
priority than the holding task, determining whether the holding task has executed 
since the semaphore was assigned to the holding task, releasing the semaphore held by 
the holding task when the higher priority task requests to take the semaphore and the 
holding task has not executed since the semaphore was assigned to the holding task; 
and assigning the semaphore to the higher priority task. 

In accordance with an example embodiment of the present invention, a system may be 
provided that includes a semaphore, and a semaphore control mechanism configured 
to release the semaphore if: a first task holds the semaphore, a second task having 
higher priority than the first task attempts to take the semaphore, and, when the 
second task attempts to take the semaphore, the first task has not executed since 
receiving the semaphore. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates a problem that may occur in conventional implementations of 
systems that include a mutual exclusion control mechanism and a priority control 
mechanism. 

4 
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Figure 2 illustrates an example use of resource stealing, in an example embodiment 
implemented according to the present invention. 

5 Figure 3 illustrates an example procedure for taking a semaphore, in an example 
embodiment implemented according to the present invention. 

Figure 4 illustrates a continuation of the example procedure for taking a semaphore 
for a requesting task that has blocked on a semaphore that is held by another task, m 
10 an example embodiment according to the present invention 

Figure 5 illustrates an example procedure for giving a semaphore, in an example 
embodiment implemented according to the present invention. 
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Figure 6 illustrates an example computing environment, according to an example 
embodiment of the present invention. 

Fl gure 7 illustrates an example memory space in an example computing environment, 
according to an example embodiment of the present invention. 

Figure 8 illustrates an example operating system queue structure, in an example 
embodiment implemented according to the present invention. 

Figure 9 illustrates an example task control block data structure, in an example 
embodiment implemented according to the present invention. 

Figure 10 illustrates an example semaphore control data structure, in an example 
embodiment implemented according to the present invention. 

30 Figure 1 1 illustrates an alternative example task control block data structure, in an 
alternative example embodiment implemented according to the present mvenUon. 
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DETAILED DESCRIPTION 



Figure 2 illustrates an example use of resource stealing, in an example embodiment 
implemented according to the present invention. The low priority task B blocks on a 
resource at 204. The resource is held by a higher priority task A. The resource is 
protected by a mutual exclusion control mechanism (for example, a semaphore), such 
that the resource cannot normally be taken from a task that is using it, irrespective of 
the task's priority. At some later time 206, higher priority task A, which holds the 
resource requested by task B, begins executing. Task A finishes using the resource at 
208, and gives the semaphore to Task B. Task B is denoted here with a circle, rather 
than a rectangle, to indicate that Task B does not actually execute at time 208. 
Instead, the resource is simply assigned to Task B during Task A's execution. At 210, 
task A again needs the resource which is now held by task B. However, task B has 
not used the resource since receiving it from task A. In fact, task B has not executed 
at all since receiving the resource from task A. Therefore, the resource can be 
"stolen" from task B and given to task A, without task B executing. Task A receives 
the resource and may continue to execute without blocking. This resource stealing 
may improve the real-time performance of higher priority task A, which no longer has 
to wait to receive the semaphore from task B. 



EXAMPLE EMBODIMENT 

An example embodiment implemented according to the present invention may be 
included as part of a computer environment, e.g., in a computer operating system. 
The example embodiment may include a priority control mechanism, a mutual 
exclusion control mechanism, mechanisms to control priority inheritance, as well as 
other conventional features of a computer operating system. 

The example embodiment implemented according to the present invention may 
include an absolute priority control mechanism. It will be appreciated that any 
conventional method of implementing a priority control mechanism may be employed. 
Each task may have an associated "priority number" indicating the task's current 
priority. In the discussion below, it is assumed that high priority tasks have a higher 
priority number than low priority tasks. It will be appreciated that other conventions 
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for indicating relative priority may be used, as long as they are used consistently. For 
example, a system could be implemented where 0 indicated the highest, rather than 
the lowest priority, and where higher numbers indicated lower priority. 

The example embodiment may include a "scheduler" which determines which task 
executes at a given time. Tasks that are candidates for execution may have entries 
included in a system "ready" queue from which the scheduler selects a task for 
execution. The scheduler may select the highest priority task with an entry in the 
"ready queue for execution. When higher priority tasks are "ready", currently 
executing lower priority tasks may be preempted and returned to the ready queue. 
Tasks may have entries stored on the ready queue in priority order, in order to 
facilitate the operation of the scheduler. Tasks that are blocked, i.e., waiting for 
resources, may be tracked by an entry in a "wait" queue. When a task receives a 
resource that it is waiting for, it may have its entry moved from the wait queue to the 
ready queue. When tasks that are executing block on an unavailable resource, their 
entry may be placed on the wait queue. 

In an example embodiment implemented according to the present invention, several 
types of semaphores may be included. The example embodiment may include 
"binary" semaphores that may be used primarily for synchronization. A binary 
semaphore may be created by invoking a procedure that creates the semaphore. A 
task may "take" the semaphore using a "take" function provided as part of the 
operating system. A second task that attempts to take a semaphore that is already 
taken by a first task may wait, either indefinitely, or for a pre-specified interval, for the 
first task to "give" or "release" the semaphore. A task may "give" or release" the 
semaphore by invoking a "give" or "release" function provided as part of the operating 
system. A semaphore that is given may be assigned to a task that currently is waiting 
to take it. The example embodiment may also include a "flush" operation for binary 
semaphores that unblocks all tasks that are waiting for a particular semaphore. The 
flush function makes binary semaphores generally unsuitable for controlling resources 
that require strictly mutually exclusive access. 

The example embodiment may also include "mutual exclusion semaphores". Mutual 
exclusion semaphores may be used to control access to shared resources. Mutual 

7 
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exclusion semaphores in the example embodiment may include several features that 
make them more suitable than binary semaphores for controlling access to shared 
resources where mutually exclusive access is desired. In the example embodiment, a 
mutual exclusion semaphore may generally only be given by the task that took it. Also 
the example embodiment, a mutual exclusion semaphore may not be given during 
interrupt service routine, a special procedure used to handle hardware interrupts 
without context switching. Also in the example embodiment, a mutual exclusion 
semaphore may not be flushed. Mutual exclusion semaphores may also be "inversion 
safe", i.e., designed to include a mechanism for priority inheritance that temporarily 
1 0 increase the priority of low priority tasks holding mutual exclusion semaphores that 
higher priority tasks are waiting for. 

When a task wants to access a shared resource that is controlled by a mutual exclusion 
semaphore, it must first "take" or acquire the semaphore associated with that resource, 

15 e.g., by invoking a "take" or request function made available as part of the operating 
system. As long as the task keeps the semaphore, all other tasks seeking access to the 
resource are generally blocked from accessing the resource. A task that invokes the 
"take" procedure for a mutual exclusion semaphore that is held by another task may 
become "blocked". The blocked task may wait indefinitely to receive the requested 

20 semaphore. Alternatively, the blocked task may wait for a specified "timeout period", 
e.g., an interval of time that may be specified in the invocation of the take function. 

When the task holding a shared resource controlled by a mutual exclusion semaphore 
finishes it use of the resource, the task may "give" or "release" the semaphore, e.g., by 
25 invoking a "give" or "release" function. When the semaphore is released, another 
waiting task may take the semaphore, allowing the task that receives the semaphore 
to use the resource. The give function may assign the resource to a waiting task 
directly. 

30 It will be appreciated that alternative approaches may be employed, where the give 
function does not immediately assign the resource to a waiting lower priority task. 
However, such an approach may require the scheduler or priority control mechanism 
to identify when the resource should be assigned to the task, e.g., when other higher 
priority tasks are neither ready to execute nor waiting for the same resource. 
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However, such an JL approach may resu,, in a significant overhead in .he 
schedu.er or priori* eon.ro, mechanic Sueh increased overhead may be acccp.a b ,« 
in a system where .here is a large amoun. of semaphore contention. 

A. examp.e embodimen, imp.emen.ed accord.ng ,o .he presen, invention may inCude 
procedures for -resource steahng" for resources pro.ec.ed by mu.ua> — 
emaphores. These procedures may be inCuded as par. of operating system .neons 
used .o .ake and g,ve mu.ua, exclusion semaphores. Resource s,ea„„ g procedure 
ma y a ,so be inCuded as par. of .he schedu.er or orher opera.ing system .unctions Ura. 
are used .o con.ro, .he execution of tasks, e.g., procedures for starting, wa,.,ng or 
pendmg tasks, and coning .as, ,ueues. „ w.„ be appreciated ,ha, .he resource 
teahng procedure, described for use wi.h mu.ua, exc,us,on semaphores cou.d =ad„y 
,e adapted for use wi.h o.her mu.ua, excursion con,o, mechanisms, or w,.h Cher 
types of semaphores. 

Example Take Procedure Including Resource Stealing 

Figure 3 iUustrates an exampte W procedure .ha. incorpora.es resource steaUng, in 
an examp,e embodiment indented according .o .he presen. invention. 

0 m step 302, a task that is currently executing anemp.s to take a mutua, excursion 
sem aphore. The task may attempt to take ft. semaphore by executing an operating 

l the semaphore jested and a timeout hrnit, e.g., an amoun. of time the .ask w„, 
25 wait before "timing out" and unb,ocking without receivmg the semaphore. 

In step 304, whether the recited semaphore is he,d by another .ask may be 
de.erm.ned. This may be accompHshed by checking a vanab.e assocrate w* 
semaphore. The vanabie may be inCuded in a semaphore con.ro, da.a smrctiu 
30 corresponds to .he rea.ues.ed semaphore. For example, .he semaphore contic ,1 d^ 
structure may co„.a,n a fe,d identifying the owning task, w.th the fie.d set to NULL 

task then the examp.e procedure may be competed by having the requesting 
guested semaphore ,n a conventional manner. However, if .he reo.ues.ed semaphore 
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is currently owned by another .ask, .hen the example procedure may proceed ,o s.ep 
306. 

to s,ep 306, whe.her .he ,ask curren.ly holding .he semaphore has a higher priority 
, .han .he rec.ues.ing ,ask may be de.ermi„ed. A htgher priori* <ask may be hold „g me 
requeued semaphore, even .hough a lower prion«y .ask is curren.ly executing, ,f he 
hi^er pnon.y .ask ,s curren.ly blocked on a differen, semaphore, .f .he ,ask holdmg 
,he semaphore has a higher priori,y .han .he requesting .ask, .hen .he guesting .ask 
may block on .he requested semaphore in a conventional manner, e.g., by removmg 
,0 the requesting ,ask from .he ready queue and placing an en.ry for .he reo.ues.ing .ask . 
on a wai, queue for the requested semaphore. The example procedure may then 
continue wi.h step 307. However, if .he requesting .ask has a higher pnori.y than he 
task holding the semaphore, then resource stealing may be possible, and the example 
procedure may continue with step 308. 

to sl ep 308, whether the'task holdmg the semaphore has executed since receiving the 
semaphore may he determined. Thts de.ermina.ton may he made by .es.mg a vanable 
associa.ec w,,h the task, where the variable indicates whether me .ask has executed 
since receiving the semaphore. This de.ermma.ion may also be made by .esting a 
20 variable assoc,a.ed w«h .he semaphore, where .he variable mdicates whether .he task 
holding the semaphore has executed since the task received the requested semaphore. 
,f the task holding the requested semaphore has executed since recemng the 
semaphore, then semaphore s,ea„ng may no, be possible, and .he .ask hoiding .he 
reques.ed semaphore may maimain control of the requested semaphore. If the .ask 
25 holding the semaphore has no, executed since receivmg the requested semaphore then 
the requesting ,ask may be able ,o s.ea. me semaphore from ,he holding ,ask. to mat 
case, .he example procedure may continue with step 310. 

In s,ep 310, ,he semaphore is stolen from .he «k holding i,. The semaphore is 
30 released without the holdmg task executing a g,ve function ca„. The holding task 
may have an entry added ,o ,he wai, queue, ,o indicate that the holding task has 
blocked on the semaphore. The requesting (ask receives the semaphore. The 
semaphore control data structure may be updated to reflect that the requesting task 
will hold the semaphore. Any o,her conventional steps that are needed to complete 
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the procedure of the requesting task receiving the requested semaphore may also be 
completed. 

In step 312, whether a timeout may be needed for the holding task may be 
determined. The holding task's last request that resulted in the holding task receiving 

5 the requested semaphore was satisfied when the holding task received the semaphore. 
However, the semaphore has now been stolen from the holding task. If the last 
request for the stolen semaphore by the holding task would have timed out had the 
holding task not actually received the stolen semaphore, the example procedure may 
continue to step 314. If the holding task would not have timed out, the example 

1 0 procedure may continue with step 316. 

In step 314, the holding task's last semaphore request may be timed out. The holding 
task's take request for the semaphore may return an appropriate time out or exception 
code that indicates the attempt to take the semaphore failed. The holding task may be 
15 returned to the ready queue. The take function may be configured to issue a return 
code even if the task has not executed since requesting the semaphore. 

In step 316, the holding task's original request to take the semaphore may be restored. 
The holding task may have an entry added to the wait queue. The holding task may 

20 wait until either the requested semaphore becomes available, or until the holding 

task's request for the semaphore times out. It will be appreciated that, depending on 
how timeouts are handled, the timeout clock may need to be restored for the holding 
task. However, as will be discussed below, the example embodiment may avoid the 
need for restoring the timeout clock by leaving the timeout clock undisturbed until the 

25 holding task has either timed out, or has executed after receiving the semaphore. 

Figure 4 illustrates additional steps of the example "take" procedure for a requesting 
task that has initially blocked on a semaphore because the semaphore was held by 
another task, according to an example embodiment of the present invention. The 
30 figure illustrates steps of the procedure that maybe followed after step 307 of the 
. procedure discussed above and illustrated in Figure 3. 

It will be appreciated that , because the requesting task has blocked on the semaphore, 
the task may have been placed on a wait queue for the semaphore, and may 

11 
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temporarily stop execution. The task may then wait to resume execution until either it 
receives the requested semaphore or the task's request for the semaphore times out. In 
either case, the task would have been moved from the wait queue for the requested 
semaphore to the ready queue, and would subsequently execute when selected from 
the ready queue by the scheduler. However, it will also be appreciated that other 
higher priority tasks may have stolen the requested semaphore from the requesting 
task while the requesting task was waiting to execute on the system ready queue. 

in step 402, the requesting task may begin execution, e.g., when selected to execute by 
the scheduler. Before this can occur, the task may have either received the requested 
semaphore, or the semaphore request may have timed out, allowing the task to be 
moved from the wait queue to the ready queue. 

In step 404, the requesting task may be checked to determine whether its semaphore 
15 request has timed out. If the request has timed out, the semaphore request may be 

timed out, e.g., by having the system "take" function return an error code that indicates 
that the semaphore request has timed out. If the request has not timed out the 
example take procedure may continue with step 406. 

20 In step 406, the example take procedure may disable interrupts or take other 

equivalent steps to prevent interruption or preemption. Steps 408-412 and 416 may 
need to be completed without interruption. 

Steps 408-412 and step 416 in the example procedure are surrounded by a dashed box, 
to indicate that these steps may be performed without interruption or preemption. 
Although interruption is prevented in the example embodiment by disabling 
interrupts, any other conventional method of preventing race conditions from arising 
may be used. 



25 



30 



m step 408, the example take procedure may check to determine whether the 
requesting task still has the requested semaphore, or if, alternatively, the requested 
semaphore has been stolen by a higher priority task. If the requesting task still has the 
requested semaphore the procedure may continue with step 410. Otherwise, the 
example take procedure may continue with step 416. 
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ta step 410, the timeout timer for the requesting task's "take" of the semaphore is 
turned oft, e.g., by removing .he requesting task's entry on the timeout queue. 

5 in step 412, an indication is made that the requesting task has run since taking the 
semaphore, e.g„ by setting a "stable" flag in the semaphore contro! data structure 
for the requested semaphore to "FALSE". This indication may prevent other tugher 
priority tasks from subsequently stealing the semaphore once interrupts are allowed, 
thereby preventing potential race conditions. 

m step 414, interrupts are unlocked, allowing normal execution by the system to 
resume. The example take procedure may subsequently return an "OK" flag or other 
indication that the task has successfully acquired the semaphore. 

, 5 In step 416, the semaphore whtch the requesting task had acquired has been stolen by 
a higher pnonty task before the requesting task has been able to execute. The 
requesting task may be replaced on the wait queue. 

in step 418, mterrupts may be unlocked allowing normal execution. Once interrupts 
20 are unlocked and the requesting task is returned to the wait queue, 

the requesting task will block or wait until it receives the semaphore agatn, or until ,«s 
request for the semaphore times out. When the task resumes execution, ,t wll 

continue with step 402. 

25 It will be appreciated that resource stealing may be possible even in situations where 
the holding task had executed since receivmg the semaphore. However, to aHow 
resource stealing where the holding task had executed since receiving the semaphore 
may requ.re procedures to track whether the resource controlled by the requested 
semaphore may safely be given to the requesting task, e.g., whether the resource had 
30 actually been used the holding task. 

1, will be appreciated tha, the steps of the example take procedure, described above, 
could be defined as a series of instructions adapted to be executed by a processor, and 
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these instruction could be stored on a computer-readable medium, e.g., a tape, a disk, 
a CD-ROM. 

Example Give Procedure Incorporating Resource Stealing 

Flg ure 5 illustrates an example "give" procedure for mutual exclusion semaphores that 
has been modified to incorporate resource stealing, in an example embodiment 
implemented according to the present invention. 

In step 502 of the example give procedure, a task finishes using a resource and may 
release the semaphore that is used to control the resource, for example, by invoking an 
operating system "give" function. The give function may have arguments winch 
include the identity of the task releasing the resource, and the identity of the 

semaphore being released. 

I„ step 504 of the example give procedure, if no other task is blocked on the 
semaphore being released, the example procedure may proceed to step 506. 
Otherwise, the procedure may proceed to step 510. Whether other tasks are blocked 
on the semaphore being released may be determined by conventional procedures for 
controlling tasks and semaphores, e.g., by checking whether there are any entnes on 
the semaphore's wait queue. Alternatively, if a system wait queue is used tnstead of 
individual watt queues for individual semaphores, the system wait queue may be 
checked to determine whether it contains entries corresponding to tasks watttng for 
the release semaphore. 

In step 506 of the example give procedure, no other task is currently waiting for the 
released semaphore. An indication may be made that no task holds the semaphore, 
for example, by setting an "owning task vanable" assorted with the semaphore. This 
variable may be included in a semaphore control data structure corresponding to the 
released semaphore. The owning task variable may be set to "NULL" or some other 
predetermined value that indicates that no task currently holds the semaphore. 
Indication may be made that the semaphore is stealable by another higher priority task, 
e g by setting a "stealable" flag in the semaphore's semaphore control data structure 
to "TRUE". Any other conventional procedures used in releasing a semaphore may 
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also be completed. Once the task has released the semaphore, the task may continue 

normal execution. 

In step 510 of the example give procedure, another task has previously blocked on the 
semaphore being released. The semaphore may be released from the releasing task 
and given to the requesting task. An indication may be made that the requesting task 
holds the semaphore, for example, by setting an owning task variable in a 
maphore control data structure corresponding to the released semaphore. Variables 
associated with both the task or the semaphore may be set to indicate that the task has 
executed since receiving the semaphore. For example, a "stealable" flag in the 
released semaphore's semaphore control data structure maybe set to indicate that the 
task receiving the semaphore has not executed since receiving the semaphore. 



now 

se: 



In step 512 of the example give procedure, the semaphore is taken from the releasing 
task and given to a lower priority requesting task. The requesting task will no longer 
be blocked on the semaphore it has received. An entry for the requesting task in a 
"wait" queue for the semaphore may be deleted. A corresponding entry in the system 
"ready" queue may be added. An indication may be made that the semaphore is 
"stealable", e.g., by setting a flag in the semaphore's semaphore control data structure. 

It will be appreciated that the example embodiment may defer resetting the timeout 
timer for the receiving task when the receiving task receives the semaphore. The 
timeout timer in the example embodiment may be reset when the receiving task- 
executes after receiving the semaphore. It will be appreciated that waiting until a task 
actually executes to reset the timeout timer avoids the problem of having to restore the 
timeout timer when a semaphore is stolen. However, it will also be appreciated that, 
alternatively, the timeout timer could be reset when the receiving task receives the 
requested semaphore, but that resetting the timer would require restoring the timer if a 
semaphore is stolen. 

When step 5 12 has been completed, the procedure for releasing the semaphore has 
been completed, and the requesting task has received the semaphore. Once the 
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procedure has been completed, if the receiving task has higher priority than the 
releasing task, the receiving task may preempt the task that has gWen the semaphore. 

It will be appreciated that the steps of the example grve procedure, described above, 
could be defined as a series of mstructions adapted to be executed by a processor, and 
these instruction could be stored on a computer-readable medium, e.g., a tape, a disk, 
a CD-ROM. 

Example Computing Environment 

Figure 6 illustrates an example computing environment 600, according to an example 
embodiment of the present invention. 

A memory space 601 may be provided as part of the computing environment. The 
memory space 601 may be addressed in any conventional manner, and may be divided 
into a plurality of memory pages 610. 



A secondary storage system 602 may also be provided as part of the computmg 
environment. The secondary storage system may include, disks, tapes, cd-roms, and 
20 other storage media. , The secondary storage system may also include interfaces to 

networks that connect the example computing environment to storage systems located 
on other computer systems. 

An operating system 604 may be included as part of the example computing 

25 environment. 

The operating system may include a priority control mechanism 612. The priority 
control mechanism may include functions for controlling the execution of tasks of 
different priorities. 

The operating system may also include a mutual exclusion control mechanism 614. 
The mutual exclusion control mechanism may be used to control access to resources 
that require mutually exclusive access by tasks, e.g., portions of the memory space 
601 and resources in the secondary storage system 602. The mutual exclusion control 
35 mechanism 614 may include functions to create, manage, and track mutual exclusion 

16 
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„ . The mu.ua, exc.usioncon.roi mechanism may aiso inciude ft.nc.ions 
semaphores. The mutual „„u ft , P <; it will be 

, 11 „,,,.«.«--~--"*-'-tn. b .^.i«.- 

5 environment. 

de.erm.nes w« — e«cu.e ana for how ion, Thes* ^ 

tpm "readv" Queue for execution. The scheduler o 
, asl cfromasys.em in determining when e>ecu.ing .ask may be 

controlling tasks. For example, timers may pro 

function for semaphores is invoked. The timeo 

a onsk tasks when timeouts have occurred, 
timeout timers and signals tasKs wn 

time „„. uueue or even, queue. The en,nes o _ m 
ti me order, i.e., .he soones. even«s are s«ored . .he head ^ ^ 

ic nr "tics" a hardware interrupt may be used to trigg 

:,ewa, q ueue.o.e S y,em.eaay^e,so,,,e 

timed out tasks may execute. 
30 , m nf . cor dine to an example 

embodl m -onhep.ese. — the operat , ng s ys.em, an, a 

S ys.em memory spaee 70 , ^ ^ ^ 

user memory space 704 .ha. may be accessed by 
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space may include memory space for the operating system executable code 706. The 
system memory space may include space for operating system queues, including a 
ready queue 708 and an event or timeout queue 712. It may be convenient to store the 
space required for these queues contiguously in the system memory space. However, 
5 it will be appreciated that conventional methods of tracking entries in the queues may 
be used that do not require a separate contiguous storage space for each queue, e.g., a 
linked list may be formed of objects or table entries corresponding to tasks that have 
entries in a particular queue. Thus the separate structure for the queues in the system 
memory may only be pointers and other configuration data, the actual contents of the 
10 queue may be stored as part of other structures in the system memory. 

The system memory space may also include storage space for semaphore control data 
structures 714 and storage for task control blocks 716. These structure may be 
included as part of linked lists defining the system ready and timeout queues. 

15 

It will be appreciated that no system wait queue is shown in Figure 7, although one 
may be provided. In the example embodiment, wait queues may be provided for 
individual semaphores, rather than as a central structure. The semaphore control data 
structure 714 may also include (or include links to) a wait queue for the corresponding 

20 semaphore. 

The user memory space 704 may include user task memory allocations 718 divided 
into smaller subsets allocated to particular user tasks. Each task memory allocation 
718 may include a code space for executable code for the task, as well as a data space 
25 to be used as workspace by the task when the task executes. 

Operating System Queue Structure 

Figure 8 illustrates an example operating system queue structure, in an example 
30 embodiment implemented according to the present invention. 

The example operating system queue structure may include a ready queue 802. The 
ready queue may contain an entry for each task that is currently ready to be executed, 
i.e., the task is not currently waiting to receive a resource or take a semaphore. Tasks' 
35 entries may be stored in the ready queue in decreasing priority order, i.e., the entry at 
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the head of the ready queue may correspond to the highest priority task currently ready 
to execute. In the example embodiment the entries in the ready queue are the task 
control blocks, and the pointers are pointers to task control blocks, i.e., the queue is a 
linked list of task control blocks. It will be appreciated that separate entries could be 
used, rather than using the task control blocks. Although not shown, it will be 
appreciated that the ready queue may be maintained as a doubly-linked list in order to 
allow more efficient management of the ready queue. It will also be appreciated that 
different data structures may be used to implement a ready queue 802, e.g., a singly 
list link, a more complex multi-linked list, a priority queue, etc. 

The example embodiment may include an example timeout or event queue 804. The 
example timeout queue may include an entry for each task presently waiting for a 
resource, where the task has specified a timeout interval, i.e., how long the task will 
wait for the resource before the resource request times out. The entries on the 
timeout queue may be stored in real time order, the soonest events first. Each entry 
may include a field specifying when the corresponding task will time out. Like the 
ready queue, the entries on the ready queue may be the task control blocks for the 
waiting tasks, i.e. the timeout queue may be formed as a linked list of task control 
blocks. 



20 



The example embodiment may include separate wait queues 806 for each resource for 
which tasks can wait. Each wait queue may include entries identifying each task 
currently waiting for a resource, e.g., waiting to take a semaphore. It will be 
appreciated that alternative queue structures may be used. For example a central 
25 queue might be used to store all tasks currently waiting for resources. 

An operating system may include one or more functions for managing the example 
operating system queue structure. For example, a "scheduler" may be used to control 
30 the execution of tasks in the system. The scheduler determines which tasks run, and 
for how long. The scheduler may also determine when a higher priority task that is 
ready to run preempts a currently running lower priority task. In the example 
embodiment, a conventional task scheduler may be used without modification. 
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It will be appreciated that when changes are made to task priorities due to priority 
inheritance that appropnate adjustments will need to be made to the operating system 
queues, e.g., entries stored in queues in priority order may need to be re-sorted. 

5 Task Control Block Data Structure 

An example task control block 901 is illustrated in Figure 9, in an example 
embodiment implemented according to the present invention. The example task 
control block may be included as part of a computer operating system. A task control 
10 block may be included for each task in the system. The example task control block 

901 may be a pre-defined memory object, if the system is implemented us,ng object- 

oriented programming techniques. 

The example task control block 901 may include a variable 902 indicative of the 
1 5 priority of the task. In the example embodiment, priority variable 902 may be 

unplemented as an integer number from 0 to some predetermined upper bound (e.g., 
255) It will be appreciated that any consistently-used convention for designating task 
priorities could be used, e.g., zero could be the highest priority or the lowest priority, 
although for clarity in this description it is assumed that lower numbers imply lower 
20 priorities. 

The example task control block 901 may also include a task state variable 904. It will 
be appreciated that the task state variable 904 may be an aggregation of different state 
bits for a task. Task states in the example embodiment may include "ready", i.e., ready 
to execute. Task states in the example embodiment may also include "wait", i.e., 
waiting for a semaphore or other resource indefinitely, without a timeout interval 
specified Task states in the example embodiment may also include "wait + delayed", 
i e waiting for a semaphore or other resource, with a timeout time interval specified. 
Task states in the example embodiment may also include "ready + delayed", i.e., the 
task has received a resource for which it was waiting and is therefore no longer 
waiting, but the task's timeout timer has not yet been reset. This state may be used 
for tasks that have received a semaphore but have not yet executed since receiving the 
semaphore Because such tasks may have their semaphore stolen, the timeout time 
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appreciated that other task states may be included. 

The exampie task con,ro, W 90. may also .nclude a Mocking semap* ,re variable 
^ ha, iden.ifies a semaphote which has caused the corresponding task to b ock. 

semaphore. It will be app w Initially the variable 906 may 

semaphore may be used, e.g., an identification number. Initially . 

be set to a "NULL" value, assuming a newly created task is no. blocked. 

The example task control block ,01 may also include a memory pointer 90S «- -may 

appreciated tha, additional memory pointers may be employed e.g„ identify 
separate code and data portions of memory allocated to the task. 

5 The example task control block 90, may also include a ready/war, queue pointer 9,0 
I! Zwai. q ueuebackpoin,er91, These po.n.ers may be used to form *e 
and ready q ^ ^ ^ and 

, ink ed ,is, of task — ^ „s maybe used identify preceding task and 
semaphore wait queues. These two po 

contains the corresponding task. The head and end of a queue may 
special link symbols, e.g., "HEAD" and "NULL". 

, ui a om mav also include timeout queue pointer 914 and 
The example task control block 901 may also in 

u , • ,„Q, 6 These pointers may be used to form the linked list or 
25 timeout queue back pointer 916. The e p ^ ^ ^ 

taskcontrolbloeksthatmaybeusedtoformthesyst^i, « 
endofaqueuemaybedeno,edwi,hspecial,inksymbo.s,e.g., HEAD 

The examp,e task control block 901 may a.so include a timeout limit 9,8. This 
30 r;eIImay,nd,ca,ea,imeu„,i,wh,ch,hecorre S ponding,askwi,,wa,,.o 

Ivethesemaphorewhichthetaskhasblockedon. Any — y^d 

conventional representation for time may be used. For example, ,n die example 
:;b:d,men,,,e,,nieou,,im..maydesi^tesarea„,meva,uereprese„.edw,tha 

pair of long integers representing die number of ties since a base ..me. 



* 



11283/31 



„ „iU be appreciated tha, many Cher variab.es may be included in .he .ask control 
Mock ,n supper, of other operating system functions. I. will also be appreciated that 
different data structures may be used for tndivdua, task control Mocks. I. will also be 
apprec.ated that different data structures may be used to store all task control Mocks m 
th e system. For example, all task control blocks in a system may be stored m a table, 
as a linked list, or other conventional data structures. 
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Semaphore Control Data Structure 

10 Figure ,0 tllustrates an example semaphore control data structure 100!, in an example 
embodiment imptemen.ed according to the present mvention. A semaphore control 
data structure may be included in a system for each semaphore in the system. The 
semaphore control data structure may be created when the corresponding semaphores 

15 created. 

It will be appreciated that any conventional data structure may be used for the 
semaphore control data structure. For example, in an object onented system, a 
semaphore control data structure may be a memory object. All semaphore control data 
structures may be stored together m a table, linked list, or other conventional data - 
structure. A semaphore control data structure may include one or more vanables, as 
illustrated in Figure 10. 

An example semaphore control data structure 1001 may inctade an identifier 1002 
which uniquely identifies the task currently owning or holding the semaphore. The 
identifier 1002 may be a pointer to the task control block for the correspond,^ task. 

will be appreciated other conventional mechanisms for identifying the owning task 
may be used, e.g., a task identification number. 

The example semaphore control data structure 1001 may include a Ml or variable 
!004 indicative of the semaphore type. This field may indicate whether the 
semaphore is a binary semaphore, a mutual exclus.on semaphore, or some other type 
of a semaphore. This field may also mclude one or more flags indicating vanous 
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properlievof ,he semaphore, e.,, a fla g indicate whether .he semaphore ,s — 
safe, whaher the semaphore can be deleted, etc. 

The examp.e semaphore contro, data structure ,00, may inCude a recursions * 
s ,006 The — count indicates the number of times the .as. current* ho.d.ng 
th e semaphore has recursive* taken the semaphore. When a task firs, ta.es a 
semaphore, the recursion count may be set to zero. 

Tne example semaphore contro, data structure ,00, may a,so mc.ude a "stea,ab,e 
, 0 „ ag - ,00S ,.e., vanab.e in,c,ive of whether the semaphore can be sto.enfrom * 
tasUthascurrent.yhoUsthesemaphore. This variab.e may be setto TRUE 
the task hoUmg the semaphore has not executed since receiving the semaphore - 
"FALSE" otherwise. When the semaphore is gtven ,„ a task while the g .vm task 
arming, the s,ea,ab,e flag is set to TRUE. When a task begins executton, the 
1 5 stealable flag is set to FALSE. 

The examp,e semaphore contro, data st ro ctur. ,00, may a,so mclude a wait ,ueue 
I tinier ,0,0. Tmspo.n.er.dent.f.estheflrstentryinthehn.edhstofen^s 

corre pondmg to tasks wait,n g for the semaphore. The entries may be task contro, 
::lofwaL g , S ks. ThewaMueueheadpotntermaybesetto-NU^w enthe 

semaphore, wait oueue is empty. B wi„ be appreciated that other convennona, ^ 
methods of manning a wait oueue for the semaphore may be emp.oyed, e g, 

„ wi„ be appreciated that other fle.ds or variab.es maybe included as par, of the 

^ We identifying a resource that rs 

example semaphore contro, data structure, e. g ., a 
controlled by the semaphore. 

ALTERNATIVE EXAMPLE EMBODIMENT 

30 An alternative example embodiment may be provided accordi„ g to the present 
inventton. In the alternative example embodiment, the schedmer may be used to 
det _„ewhe.hera S e m aphore h asbeen sto.en from a task when the task executes. 
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alternative example task control may 

5 include a variable assoca.ed w,.h .he .ask <h 

receiving .he semaphore, e.g„ a "run since taken flag 1 02. T 

, ,.,,,rte a "orevious timeout* variable 1104. 
task control block may also .nclude a previo 

, j. ,i„ ; , the semaphore is not held by 
When a semaphore is aeoutred by a task d,rec„y, ,,, P 
,„ another task when 1, is reouested, the "run smce taken nag may 
because the taking task is presently executing. 

fcore , s received by the task during another task's execution, the run 
When a semaphore ,s receive y ^ fe 

s ema P hore ,s rece.ved by .he taskdu g for ^ 

„ ra eo„, variable 1 .04 may be se, to save a record of ^ 
se maphore tha, was ^s, received would have „med t , be 

task's last acquired semaphore. 

the variable assorted wuh the «a k ^ ^ ^ ^ 
.king a semaphore may be set o rndica e h ^ ^ ^ ^ ^ 

variable associated wtth semaphores held by the task . ^ ^ 

30 ^sincetakmgthosesemap J. ^ " ^ may , set to . TRUE ". Se..in g ,e 
execute, the run smce taken flag 1 102 ^ 

, n a o to TRUE will prevent a higher priority task rrom 
run since taken flag to TRUtwi p ,,„„- „ r other variable recording the 

semaphore from the task. The "blocked on semaphor or other 
identity ofthe las, acouired semaphore may also be cleared. 
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semaphore sought by .he h.gherpnonty task, and 

FALSE, the semaphore may be stolen by the higher pnonty task The «*m P 
rl mav be determined by examining the blocked on semaphore variable, as 

1D z^:^^^> m t^ 



MODIFICATIONS 

15 to the precedmg specification, the present mventton has been descnbed with reference 

« «t forth in the claims that follow. The 
spin, and scope of the present ,nve„,»n s . «h ^ ^ 

specification and drawings are accordmgly to be regarded 

20 restrictive sense. 
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